At the beginning of DebCamp, Zack started the RCBC the Release Critical Bug squashing Contest. Two weeks later not only DebConf10 is over but we also have results for the RCBC:

In summary: It was a huge success, we managed to fix

• 139 RC bugs in testing/unstable
• 79 RC bugs in stable

And the winners are:

• Stable: Gerfried Fuchs (77 bugs)
• Testing/unstable: 1. Moritz M hlenhoff (32 bugs), 2. Nico Golde (17 bugs), 3. Alexander Reichle-Schmehl (16 bugs)

All details can be found at http://wiki.debconf.org/wiki/DebConf10/RCBC.

The winners who haven't collected their prizes at the closing ceremony will get them be snail mail.

Finally let me thank

• our donors of the prizes
• Micah and Zack for initiating the contest
• Mehdi for being my co-judge
• all participants who hugely improved Debian in the last two weeks

You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category. There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already^[1] given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected. If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years.

• Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
• Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
• For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
• So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
  • Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
    • If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
    • If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
  • Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
  • If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.

I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place! Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!

---

^[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you:
select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';

/debian permanent link Comments: 0

Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Good flamewar training. And people considered that to be the fun part. After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard. In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given. The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times. The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess. For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people. On the other hand, there is only so much abuse one can take...
ObTitle: Ennio Morricone - The Good, The Bad and The Ugly

/debian permanent link Comments: 5

Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Good flamewar training. And people considered that to be the fun part. After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard. In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given. The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times. The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess. For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people. On the other hand, there is only so much abuse one can take...
ObTitle: Ennio Morricone - The Good, The Bad and The Ugly

/debian permanent link Comments: 8

Alright, get ready for the next round of music links. This time I stumbled upon an old (and still) favorite band of mine while looking for references to Max Headroom: Art of Noise. You most probably have heard the one or the other song from them, they are featured pretty often. Here they are:

• Moments In Love: Well known song, I suspect.
• Peter Gunn: Also very well known and used often. You have to wait a bit for the music to hook in, there is an intro in the video.
• Paranoimia: Third great song you might have heard somewhere already. Absolutely lovely song indeed.

It's really sad to see such great bands to pass away. But it's still the perfect music to have running in the background when hacking along. Highly motivating, great to hum along. Oh, and you might ask, where is the connection to Max Headroom. Here it is, in a special version of Paranoimia featuring Max Headroom! Enjoy!

I got convinced to hold an IRC talk on usage of the Debian BTS in #ubuntu-classroom and thought it might be interested to other children distributions of Debian, too also for regular Debian users. So feel invited to attend it. It will be held in #ubuntu-classroom on irc.freenode.net on Thursday, 22nd of July, at 18:00 UTC. For those who have never attended such a session yet, you might want/need to also join #ubuntu-classroom-chat too and raise questions in there, the main channel will be set to moderated. I will try to cover basic usage like querying the web interface, reporting new bugs and also more deeper handling of bugs, including version tracking issues, and will try to address raised questions as good as possible. Hope the session will be helpful to some and be able to address some questions like why some bugs aren't getting archived even though they are closed for ages. :) IRC logs will be available for the convenience of those who can't make it. So long!

Working on and for Debian for the whole millennium already it would had been hard to not notice Ubuntu through the times. Given that fixing bugs in the package is in the interest of all involved parties I started to get curious for the packages I maintain in Debian what users of Ubuntu might have filed against them. Given that a fair amount of those actually do also apply to Debian I started to fix them too. Though, some bug status isn't able to use as an outsider, and given my approach to perfection not wanting to have packages in a bad shape in a release I started to dig a bit further into the procedures and applied to be accepted as a Ubuntu Developer, more specifically as a MOTU, which gives me the possibility to directly ask for syncrequest instead of having to go through a sponsor, or set wontfix status for bugreports in my packages that simply doesn't make sense to get implemented. Last week I got accepted into that state and I'd like to thank for all the nice and encouraging feedback along the path (including some "What? I thought you were MOTU since ages already??" responses). Let's see how much I really need it, my approach is rather to reduce Ubuntu diffs instead of having to work on them. I though understand that at times close to the releases there can be a need for them, as can be seen in that the package I have to put most effort into (wesnoth-1.8) has a Ubuntu diff in the last lucid release. And because Ubuntu already is in DebianImportFreeze I did a syncrequest for gitolite. Thanks for accepting me so quickly and rather bureaucratic! And no, Laney, I won't give the talk tomorrow because of this just on my own. ;)

This Monday I was again at concert of Grossstadtgefl ster, and it was again one of the best concerts I've visited. Their new album again has again great songs on it like the former two, and their live performance is truly worth it. Besides they are charming like hell offstage, too. Jen, Raphi and Chriz, I simply love you! It's hard to choose which songs to put here because there are way too many great ones, so feel free to dig around yourself if you like them:

• Weil das morgen noch so ist: Their current single, great video, giving a good impression of their style and the fun they have doing this.
• Lebenslauf: Great song from their former album.
• Fehler: So much truth in the lyrics, so much touching the heart.

Enjoy!

"Today is the greatest day I've ever known," this is the line that is spinning around today in my head because of many little things that happened. And it's this time of the month anyway for putting up another band feature into this little blog of mine. So here they are, one of the great bands of the nineties, and like many of them, back after a break again: The Smashing Pumpkins, and these are their featured songs:

• Today: The song with the initial mentioned catchphrase. Unfortunately not the official video because in those versions the music is strangely broken. If you want to match it yourself, you can still watch it here: Today (true video, broken music)
• Disarm: From the same great album, and one of their songs that gives me goosebumps.
• Bullet With Butterfly Wings: Another of their great songs and videos for which they are known.

Hope you enjoy this small distraction once a month. I hope I can keep up with it, it's not a question of material, there are too many great bands out there that I'd like to share with others. :)

We ain't dead. A long time has passed since I last wrote on this topic, and much happened unfortunately (for this effort) in other areas. This doesn't mean that this effort is being abandoned. So here is the next big step: A gitweb theme using Kalle's proposal. I enabled it on my own gitweb installation so that people can see it live and test it. Feel free to clone it from there, too. Enjoy!

Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package. The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch. So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages. Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!

My SO did had an extremely good idea for my birthday this year: We went to a concert of Ich + Ich. We both were a bit sceptical beforehand but actually we were both in agreement about that it was one of the finest concerts we have been to. I want thus to share some of the great songs of the band with you:

• Universum (Universe): I am thinking of my son when listening to this sweet song.
• Stark (Strong): Not only the title but the lyrics.
• Dienen (Serve): Probably the best known of their songs.

Enjoy!

On 20th of March, at five to midnight, we have released out most straining and time consuming project ever. Its codename is Simon Andr and we are pleased that it was (more or less) a smooth release process with just a minor delay of three days but the best don't release on time but when it is ready. Because everyone loves screenshots, and a few might be viewed on our dedicated Screenshot Page, for completeness this announce contains one: After one week into the release we have to say the feedback and the interest so far is pretty good, the maintenance is requesting its toll, but nothing really unexpected happened so far. We look into a bright future! Thank you for your attention, enjoy the nice spring weather!

Gerfried Fuchs:

I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too.

I think that some DPLs are overwhelmed by the amount of requests they receive, and more importantly, are overwhelmed by the feeling of futility from perceiving that it is impossible to fix the things that they had intended to fix. So, unless there are other factors I would need to adapt to, I would try to discourage the number of private requests, and to not lose hope and faith in Debian. I imagine that delegation could be very useful in both these areas. Gunnar Wolf:

What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect?

The DPL is theoretically one of the most important checks against the power of delegates. The absence of a DPL would thus increase any power imbalance in the the project, and likely to make the fighting between core teams even more political and harmful. Communities and teams are destabilized by egos because people stop paying attention to their healthy shared goals and the people around them and instead focus on their own individual success. So if the project were to achieve some kind of anarchic utopia where this is not an issue, I could imagine that the DPL would be the last remaining ego threat, and removing that role would make things better. However, we are nowhere near that now, and I think the DPL can do more good on this front. Yavor Doganov:

What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is "goodness" or you're in the "good riddance" camp?

I definitely think that one of our strengths is being available on a large number of architectures, and beyond that, providing nearly identical experiences on each of those platforms. I am saddened when porters or package maintainers make decisions to stray from the norm on a particular architecture, because I truly enjoy the consistency. I have run Debian on i386, sparc, hppa, powerpc, amd64, and in the few cases where something was different, I found it irksome. However, there is definitely a point where the cost in maintaining a release architecture far exceeds the benefit, and at that time I think we must regretfully bid it farewell. So you are right that porters are a precious resource, and as DPL I would try to reduce their attrition. Speaking as a former porter, I found the unresponsiveness and uncooperativeness of certain buildd maintainers (especially when not porters themselves) to be extremely demotivating. I would try to find a way mitigate porters being demotivated in such a way.

Ben Hutchings writes:

You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.

You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.

A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS. It isn't or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:

--- /usr/lib/urxvt/perl/matcher.distrib	2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda	2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
 # Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
 
 my $url =
-   qr 
+   qr (?:
       (?:https?:// ftp:// news:// mailto: file:// \bwww\.)
       [a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
       (
          \([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)  # Allow a pair of matched parentheses
          [a-zA-Z0-9\-\@;\/?:&=%\$_+*~]  # exclude some trailing characters (heuristic)
       )+
+      ) \#[0-9] 4, 
     x;
 
 sub on_user_command  
@@ -145,6 +146,7 @@
          my @begin = @-;
          my @end = @+;
          if (!defined($col)   ($-[0] <= $col && $+[0] >= $col))  
+            $match =~ s/^#/http:\/\/bugs.debian.org\//;
             if ($launcher !~ /\$/)  
                return ($launcher,$match);
               else  

The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!

A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success. This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them. Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!

The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help: Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de". Much thanks in advance!

On Wednesday I got DAM approval and since Saturday late evening I m officially a Debian Developer. Yay! :-) My thanks go to

• Christoph Berg (Myon) whom I know for more than a decade since we studied together, and who s career in Debian was way faster than mine, but who on the other hand probably knows me better than nobody else in Debian which made him the perfect advocate;
• Bernd Zeimetz (bzed) whom I know from my times at DaLUG and who was the friendliest Application Manager I could imagine he s probably also one of the fastest (8 days from application to AM report :-);
• Luca Capello (gismo), who was the most demanding but also most inspiring sponsor I ever had and who became a very good friend after we found each other over my package conkeror.
• Arne Wichmann (Y_Plentyn) for being my first drop-in center for Debian questions (like can I directly dist-upgrade from 2.0 to 3.0? :-);
• Martin Zobel-Helas (zobel) who was always encouraging me to continue exploring new sides of Debian;
• Gerfried Fuchs (Rhonda) just for being there (and for being a package maintainer with good relations to upstream ;-);
• my coworkers at the IT Services Group of the Department of Physics at ETH Zurich, who always found new challenges in Debian for me to solve;
• and all those others who offered to also advocate me (e.g. Otavio Salvador) or sponsored my packages so far (or at least offered to do so), e.g. Alexander Wirt (formorer), Martin F. Krafft (madduck), Robert J rdens (jordens),

As Bernd cited in his AM report, my earliest activity within the Debian community I can remember was organising the Debian booth at LinuxDay.lu 2003, where I installed Debian 3.0 Woody on my Hamilton Hamstation hy (a Sun SparcStation 4 clone). I wrote my first bugreport in November 2004 (#283365), probably during the Sarge BSP in Frankfurt. And my first Debian package was wikipedia2text, starting to package it August 2005 (ITP #325417). My only earlier documented interest in the Debian community is subscribing to the lists debian-apache@l.d.o and debian-emacsen@l.d.o in June 2002. I though remember that I started playing around with Debian 2.0 Hamm, skipping 2.1 (for whatever reasons, I can t remember), using 2.2 quite regularily and started to dive into with Woody which also ran on my first ThinkPad bijou . I installed it over WLAN with just a boot floppy at the Chemnitzer Linux-Tage. :-) Anyway, this has led to what it had to lead to a new Debian Developer. :-) The first package I uploaded with my newly granted rights was a new conkeror snapshot. This version should work out of the box on Ubuntu again, so that conkeror in Ubuntu should not lag that much behind Debian Sid anymore. In other News Since Wednesday I own a Nokia N900 and use it as my primary mobile phone now. Although it s not as free as the OpenMoko (see two other recent posts by Lucas Nussbaum and by Tollef Fog Heen on Planet Debian) it s definitely what I hoped the OpenMoko will once become. And even if I can t run Debian natively on the N900 (yet), it at least has a Debian chroot on it. :-) A few weeks ago, I took over the organisation of this year s Debian booth at FOSDEM from Wouter Verhelst who s busy enough with FOSDEM organisation itself. Last Monday the organiser of the BSD DevRoom at FOSDEM asked on #mirbsd for talk suggestions and they somehow talked me into giving a talk about Debian GNU/kFreeBSD. The slides should show up during the next days on my Debian GNU/kFreeBSD talks page. I hope, I ll survive that talk despite giving more or less a talk saying Jehova! . ;-) What a week.

<comment />

Your Expectations
I won't fulfil them for you
they are only yours Feeling been let down
it is understandable
but it's also wrong There are more than me
who can do the piece of work
why just bug me then? Effect is stop work
so that others won't expect
your problem is solved

German Version If you are looking for some packages to take care of within Debian, take a look at this list and feel free to contact me if you are interested.